Therapy management system

ABSTRACT

Stored data is accessed over a computer network through a network data manager. Data may be stored and transferred to the network data manager from a product device using an uploader application. In one aspect, a request message containing an access requestor identifier is received at the network data manager from a client device for access to a data storage facility. The network data manager determines if the access requestor identifier is associated with a data record that identifies a product device having a registration record, and if it does, the network data manager transmits a data link to the client device, wherein the data link provides access to the data record by the client device over the computer network for a predetermined time period such that access to the data record is halted upon expiration of the predetermined time period. The client device may comprise, for example, a desktop or laptop computer. The product device, for example, may comprise a portable insulin pump that can be connected to the computer for data transfer to and from the network data manager.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 13/564,188filed Aug. 1, 2012, which claims the benefit of priority of thefollowing co-pending U.S. Provisional patent applications: U.S.Provisional Patent Application No. 61/513,998 entitled TherapyManagement System, filed Aug. 1, 2011 by S. Daoud et al.; U.S.Provisional Patent Application No. 61/656,731 entitled TherapyManagement System, filed Jun. 7, 2012 by S. Daoud et al. Priority of thefiling dates of Aug. 1, 2011 and Jun. 7, 2012 are hereby claimed, andthe disclosures of each of the Provisional patent applications is herebyincorporated by reference. This application hereby incorporates byreference in their entirety each of the following commonly-owned patentsand patent applications: U.S. Provisional Patent Application No.61/230,061 entitled Infusion System and Methods for Using Same, filedJul. 30, 2009, by P. DiPerna et al.; U.S. patent application Ser. No.12/846,688 entitled Infusion Pump System with Disposable CartridgeHaving Pressure Venting and Pressure Feedback, filed Jul. 29, 2010 by P.DiPerna et al.; U.S. patent application Ser. No. 12/846,706 entitledInfusion Pump System with, titled Infusion Pump System with DisposableCartridge Having Pressure Venting and Pressure Feedback, filed Jul. 29,2010, by G. Kruse, et al.; U.S. patent application Ser. No. 12/846,720,entitled Infusion Pump System with Disposable Cartridge Having PressureVenting and Pressure Feedback, filed Jul. 29, 2010, by D. Brown, et al.;U.S. patent application Ser. No. 12/846,733, entitled Infusion PumpSystem with Disposable Cartridge Having Pressure Venting and PressureFeedback, filed Jul. 29, 2010, by M. Michaud, et al.; U.S. patentapplication Ser. No. 12/846,734, entitled Infusion Pump System withDisposable Cartridge Having Pressure Venting and Pressure Feedback,filed Jul. 29, 2010, by P. DiPerna, et al.; PCT Patent Application No.PCT/US2010/043789, entitled Infusion Pump System with DisposableCartridge Having Pressure Venting and Pressure Feedback, filed Jul. 29,2010, by P. DiPerna, et al.; U.S. patent application Ser. No.10/200,109, entitled Infusion Pump and Method For Use, filed Jul. 19,2002, by S. Mallett; U.S. patent application Ser. No. 11/462,962,entitled Variable Flow Reshapable Flow Restrictor Apparatus and RelatedMethods, filed Aug. 7, 2006, by P. DiPerna; U.S. patent application Ser.No. 12/039,693, entitled Adjustable Flow Controllers for Real-TimeModulation of Flow Rate, filed Feb. 28, 2008, by P. DiPerna; U.S. patentapplication Ser. No. 12/189,070, entitled Flow Prevention Regulation,and Safety Devices and Related Methods, filed Aug. 8, 2008, by P.DiPerna; U.S. patent application Ser. No. 12/189,064, entitled System ofStepped Flow Rate Regulation Using Compressible Members, filed Aug. 8,2008, by Paul DiPerna; U.S. patent application Ser. No. 12/538,018,entitled Two Chamber Pumps and Related Methods, filed Aug. 7, 2009, byPaul DiPerna; U.S. patent application Ser. No. 12/020,498, entitled TwoChamber Pumps and Related Methods, filed Jan. 25, 2008, by Paul DiPerna;U.S. patent application Ser. No. 12/468,795, entitled Disposable PumpReservoir and Related Methods, filed May 19, 2009, by Paul DiPerna; U.S.patent application Ser. No. 12/260,804, entitled Flow RegulatingStopcocks and Related Methods, filed Oct. 29, 2008, by Paul DiPerna;U.S. patent application Ser. No. 12/393,973, entitled Slideable FlowMetering Devices and Related Methods, filed Feb. 26, 2009, by PaulDiPerna; U.S. patent application Ser. No. 12/714,299, entitled Methodsand Devices for Determination of Flow Reservoir Volume, filed Feb. 26,2010, by Michael Rosinko et al.; U.S. patent application Ser. No.12/563,046, entitled Solute Concentration Measurement Device and RelatedMethods, filed Sep. 18, 2009, by David Brown; U.S. Patent ApplicationNo. 61/392,858, entitled Analyte Monitoring Systems and Methods of Use,filed Oct. 13, 2010, by David Brown et al.; PCT Patent No.PCT/US2009/044569, entitled Disposable Pump Reservoir and RelatedMethods filed May 19, 2009, by Paul DiPerna; U.S. Patent Application No.61/054,420, filed May 19, 2008, by Paul DiPerna; PCT Patent ApplicationNo. PCT/US2009/057208, entitled Flow Regulating Stopcocks and RelatedMethods, filed Sep. 16, 2009, by Paul DiPerna et al.; U.S. PatentApplication No. 61/054,420, entitled Disposable Pump Reservoir andRelated Methods, filed May 19, 2008, by Paul DiPerna; U.S. PatentApplication No. 61/097,492, entitled Flow Regulating Stopcocks andRelated Methods, filed Sep. 16, 2008, by Paul DiPerna; U.S. PatentApplication No. 61/156,405, entitled Methods for Determination of PumpSensor Integrity and Calibration of Pumps, filed Feb. 27, 2009, byMichael Rosinko et al.; U.S. Patent Application No. 61/184,282, entitledMethods and Devices for Determination of Flow Reservoir Volume, filedJun. 4, 2009, by Michael Rosinko et al.; PCT Application No.PCT/US2009/057591, entitled Solute Concentration Measurement Device andRelated Methods, filed Sep. 18, 2009, by David Brown; U.S. PatentApplication No. 61/098,655, attorney entitled Solute ConcentrationMeasurement Device and Related Methods, filed Sep. 19, 2008, by DavidBrown; U.S. Patent Application No. 61/102,776, entitled SoluteConcentration Measurement Device and Related Methods, filed Oct. 3,2008, by David Brown; U.S. Pat. No. 7,008,403, entitled “Infusion Pumpand Method for Use” by S. Mallett; U.S. Pat. No. 7,341,581, entitled“Infusion Pump and Method for Use” by S. Mallet; U.S. Pat. No.7,374,556, entitled “Infusion Pump and Method for Use”, by S. Mallet;U.S. Patent Application Publication No. 2007/0264130, entitled “InfusionPumps and Method for Use”, filed May 4, 2007 by S. Mallett; and U.S.Patent Application Publication No. 2009/0191067, entitled “Two ChamberPumps and Related Methods”, filed Jan. 25, 2008 by P. DiPerna; U.S.Provisional Patent Application Ser. No. 61/511,220 filed Jul. 25, 2011by P. DiPerna et al. and entitled “Multi-Reservoir Infusion Pump Systemsand Methods, and U.S. patent application Ser. No. 13/474,032, entitled“Methods and Devices for Multiple Fluid Transfer”, filed May 17, 2012 byT. Metzmaker et al. All of the above-listed patents and applications areincorporated by reference herein in their entirety.

BACKGROUND

Many electronic devices maintain a data log of information to keep arecord of their operational status, use history, and other parameters.Such electronic devices can be used for controlling a variety ofoperations, such as transmitting data. In the context of electronicmedical devices such as infusion pumps and the like, they may be usedfor dispensing or releasing medicaments, including fluids and othermaterials such as insulin and related medicaments. The data log mayprovide, for example, a history of transmitted or received data, dataassociated with substances or fluids such as on-board and dispensedvolume, composition, lot number, and other characteristics, as well asoperational parameters relating to transmitting, dispensing or releasingsuch substances or fluids. These electronic devices may not includesufficient memory to maintain a running, cumulative record of these dataover an extended time period, or there may be a need for such cumulativedata or other non-cumulative data to be backed-up, mirrored, or simplystored elsewhere for archival or other purposes. Therefore, these datamay be maintained at one or more locations that are remote from thedevice, such as, e.g., a remote computing device or a network datastorage facility that may have more extensive data storage capacity thanthat on the electronic device. As the device continues to operate, datasuch as those comprising a data log and/or other operational information(which such operational information may or may not be in a data log) mayneed to be sent to, transferred to, or otherwise maintained at a remotelocation such as a network data storage site to meet various needs ofthe users of and manufacturers of such devices.

In most cases, privacy concerns for the data generated by the electronicdevice will encourage careful control of access to such data by using avariety of authorization schemes. If the device is used for medical orpatient care purposes, then such privacy and other data securityconcerns may mandate data security schemes. In the U.S., for example,the Health Insurance Portability and Accountability Act (HIPAA) of 1996established national standards for electronic health care transactionsand for the security and privacy of health data. Other such privacymandates for patient-related and consumer-related data exist outside theU.S. as well.

For example, portable medicament infusion devices, such as infusionpumps, are used to regulate the dispensing of fluids such as insulin andother medicaments to a patient. These electronic devices may be inconstant or frequent operation and may store data relating to, e.g., thedispensing of medicaments such as insulin to the patient, data relatingto various operational parameters of the pump, and the like. Such data,particularly if it is cumulative in nature, may be more than can beaccurately and safely stored in the memory of the infusion deviceitself. It may also be desired to store all or selected portions of suchdata at one or more alternative sites such as, e.g., a remote computingdevice or a network data storage facility. Such remote locations may beused to archive such data, enable analysis thereof for the patient, thehealth care provider, the manufacturer, and even government regulatoryauthorities, and for other purposes. It is therefore desirable tomaintain some or all of such data in a format that is available to meetsuch needs.

It is known to establish and use network data facilities for storage ofdata such as portable insulin pump data. Access to such data, however,can be cumbersome and protracted. In some cases, access to the networkstored data requires the presence of the actual insulin pump at thecomputer or other device being used to obtain access. In other cases,data transfer can be a relatively slow and cumbersome process. Moreover,once access to such data is granted and an authorized communication pathis established, it may be desirable or necessary to carefully controlsuch access so that third parties are not able to use the communicationpath to gain unauthorized access to the data.

Easier access to the network stored data and more secure data transferare desired improvements. The present invention addresses these needs.

SUMMARY

Disclosed herein are techniques for accessing stored data over acomputer network through a network data manager. In one aspect, arequest message containing an access requestor identifier is received atthe network data manager from a client device for access to a datastorage facility. The network data manager determines if the accessrequestor identifier is associated with a data record that identifies aproduct device having a registration record, and if it does, the networkdata manager transmits a data link to the client device, wherein thedata link provides access to the data record by the client device overthe computer network for a predetermined time period such that access tothe data record is halted upon expiration of the predetermined timeperiod. The client device may comprise, for example, a desktop or laptopcomputer. The product device, for example, may comprise a portableinsulin pump that can be connected to the computer for data transfer toand from the network data manager.

In another aspect, data transfer over a computer network from a productdevice is accomplished with an uploader application executing at a hostdevice, such that the uploader application authenticates the productdevice, extracts a data log from the authenticated product device, anduploads the extracted data log to a data record at a data storagefacility over the computer network. The uploader application can receivea data link at the host device from the network data manager in responseto uploading of the extracted data log, and generates a display of thereceived data link, wherein the data link provides access to the datarecord by the host device over the computer network for a predeterminedtime period such that access to the data record is halted uponexpiration of the predetermined time period.

In other aspects, access to data is controlled such that access isautomatically terminated such that an unattended but previouslyauthorized device cannot be used to gain access. For example, thenetwork data manager may send an access grant message to the clientdevice for access to the stored data and receives a data request backfrom the client device. The network data manager will then provide therequested data record to the client device over the computer networkonly if the predetermined time period for the data link has not expired.In this way, access to the stored data is securely controlled andunauthorized access is less likely. In yet another aspect, the productidentifier associated with the registration record at the network datamanager may relate to a product device, and the product device andclient device may be integrated together into a single device. Forexample, the product device (and client device) may comprise an insulinpump device that directly communicates with the network data manager.

Other features and advantages of the present invention should beapparent from the following description of preferred embodiments thatillustrate, by way of example, the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system in accordance with the invention.

FIG. 2 is a flow diagram that illustrates operation of the data managerof FIG. 1 in authenticating.

FIG. 3 is a flow diagram that illustrates operation of the uploader ofFIG. 1 in processing a product device.

FIG. 4 is a state diagram that illustrates operation of the uploader ofFIG. 1.

FIG. 5 is a state diagram that illustrates the device detectionoperation shown in FIG. 4.

FIG. 6 is a state diagram that illustrates operation of the standbyoperation shown in FIG. 4.

FIG. 7 is a state diagram that illustrates the authentication operationshown in FIG. 4.

FIG. 8 is a state diagram that illustrates the extract logs operationshown in FIG. 4.

FIG. 9 is a state diagram that illustrates the upload operation shown inFIG. 4.

FIG. 10 is a state diagram that illustrates the Done operation shown inFIG. 4.

FIG. 11 is a screen shot for a computer accessing the network datamanager illustrated in FIG. 1.

FIG. 12 is a screen shot for a computer with a single device connectedwhile accessing the network data manager illustrated in FIG. 1.

FIG. 13 is a screen shot for a computer with multiple devices connectedwhile accessing the network data manager illustrated in FIG. 1.

FIG. 14 is a screen shot for a computer at the start of data loguploading while accessing the network data manager illustrated in FIG.1.

FIG. 15 is a screen shot for a computer after successful uploading tothe network data manager illustrated in FIG. 1.

FIG. 16 is a screen shot for a computer accessing the network datamanager that shows automatic cancellation of the data link.

FIG. 17 is a screen shot for a computer accessing the network datamanager that shows automatic logout of an inactive user.

FIG. 18 is a flow diagram that illustrates operation of the systemillustrated in FIG. 1 for data sharing with third parties.

FIG. 19 is a screen shot for a computer accessing the network datamanager that shows data sharing with third parties.

FIG. 20 is a screen shot for a computer accessing the network datamanager that shows data entry of an email address for data sharing.

FIG. 21 is a screen shot for a computer accessing the network datamanager that shows selection of a data sharing invitee from a list.

FIG. 22 is an illustration of an exemplary infusion pump device in whichthe features described herein are incorporated.

FIG. 23 is a block diagram of the device illustrated in FIG. 22.

FIG. 24 is a screenshot of an invitation message sent in response to auser request to share data with a third party.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a system in accordance with the inventionthat shows a product device 102 that communicates over a computernetwork 104 with a data system 106. The product device communicates witha network data manager 108 through an uploader application 110. Theuploader is a computer software application that performs operations ofauthentication and data transfer between the product device 102 and thenetwork data manager 108. The uploader typically is installed at a hostcomputer 112. The uploader application 110 manages, e.g., product deviceauthentication, transfer of product device data from the product deviceto the network data manager, and receipt of stored product device datafrom the data manager. That is, the uploader application is a networkclient of the network data manager. Product device data may include, forexample, operational details of the device, information regarding ahistory of transmitted or received data, data associated with substancesor fluids such as on-board and dispensed volume, composition, lotnumber, and other characteristics, as well as operational parametersrelating to transmitting, dispensing or releasing such substances orfluids.

The uploader application 110 of the system of FIG. 1 communicates withthe data manager 108 while executing on a device having a processor,memory, display, and network communication interfaces sufficient forcommunication with the network data manager. Other computer resourcesfor more convenient operation may be provided as well. Typically, theuploader application is hosted on the host computer 112 and the hostcomputer is a client device to the network data manager. The hostcomputer communicates with the product device 102 for product dataincluding data logs, which the host computer transfers to the networkdata manager 108. Thus, the host computer 112 and product device 102 anduploader application 110 comprise a system for transferring data overthe computer network 104. If the product device 102 has sufficientresources, such as a processor, memory, display, and networkcommunication interfaces, then the uploader application 110 can resideon, e.g., the product device, and in that situation the product devicecan communicate directly with the network data manager 108 over thenetwork 104. Additionally in that case, the host computer 112 and theproduct device 102 are integrated together into a single device thathosts the uploader application 110 and is a client device to the networkdata manager. That is, the integrated host computer and product devicecomprise a system having sufficient resources, such as a processor,memory, input/output components, and network communication interfaces,to carry out the functions described herein.

The network data manager 108 of the data system 106 may receive arequest message for access to data stored at a data storage facility114. The data storage facility is adapted to store large amounts of datafor access by computers and may comprise, for example, multiple diskdrives, solid state disk drives, semiconductor memory, and/or othersuitable storage devices. The data stored at the data storage facility114 may comprise all or portions of data transferred from the productdevice 102, including the product device data noted above. The requestmessage includes an access requestor identifier, to identify an owner ofa product device or to identify a third party who is neither the ownerof the product device nor the network data manager. The third party maycomprise, for example, a physician and/or an authorized member of thephysician's staff, a representative from a partner device producer, aclinician, a certified diabetes educator (CDE), and the like. If thenetwork data manager determines that the access requestor identifier isassociated with a data record that identifies a product device that hasa registration record or that otherwise identifies an authorized party,such association may be used to confirm that the access requestor hasbeen authorized. The data record to identify authorized parties may begenerated through a process such as a prior registration process withthe data storage facility 114 through the network data manager 108. Thatis, a registration record for a product device 102 includes identifiersof any product device owners or third parties who have registered withthe network data manager or have otherwise been previously authorized togain access to data of the product device.

As explained in greater detail below, third parties may register withthe network data manager in response to an invitation initiated by aproduct device owner and sent to the third party. In the exemplaryembodiment described herein, the network data manager generates aninvitation request pop-up window to a user who has logged in to theiraccount and who requests inviting someone with whom the user will sharedata. The third party responds to the invitation by providingregistration information to the network data manager, which stores theregistration information in a data record that is associated with theproduct device 102. The registration data record is stored in the datastorage 114 along with other information relating to the product device,such as product model number, serial number, name and address ofpurchaser (owner and/or user) of the product device, and the like.Additional data that may be maintained in the registration data recordwill depend on the product device. For example, if the product device isa portable insulin pump, additional data in the registration data recordmay relate to therapy settings for the pump, such as insulin deliverysettings, daytime settings, night settings, dosage size and frequency,and the like, as described, for example, in U.S. patent application Ser.No. 12/846,688 to DiPerna et al. filed Jul. 29, 2010. Other data thatmay be acquired and stored in the registration record includes the emailaddress used as the user name to login to the network data manager, thepassword used to authenticate the user, a secret question (e.g. selectedby the registrant from a list) and the answer to the secret question,date of birth. If the user is under 13, in addition to capturing thepatient's information mentioned above, the system also maintainsregistration information from the caregiver or the parent, such as firstname, last name, email address, and date of birth for the caregiver orparent. Some or all of the information described above may be maintainedin the registration information, depending on whether the registrant isa user of the product (patient) or a third party.

After the network data manager 108 determines that the access requestoris authorized, the network data manager transmits a data link to therequesting client device, wherein the data link provides access to thedata record by the client device over the computer network 104 butautomatically expires, canceling access. For example, the data link maybe active only for a predetermined time period, such that access to thedata record is halted upon expiration of the predetermined time period.The data link typically comprises an Internet link that is accessed viaan Internet browser application executing on the client device.Accessing the Internet link takes the browser application to a Web site116 in accordance with the authorization of the data manager 108.

Attempting to access the data link after it has been canceled willresult in an expired link message. This increases data security andhelps safeguard the privacy of user data. For example, FIG. 16 shows apop-up window 1602 that appears in a browser if a user is accessing thenetwork data manager through an Internet browser application and hasattempted to access the data link after it has been canceled. Othermeans of providing automatic canceling of the data link may be provided,such as requiring a supplemental authentication step to remain active,where the supplemental authentication step may require entering apassword, providing biometric input, or the like. The automaticcanceling of the data link helps limit the chance of unauthorized accessor viewing, such as where a legitimate user gains access through adesktop computer and then leaves the computer unattended. When the linkis canceled, the report window is closed. The automatic canceling of thedata link ensures that a stranger who comes upon the computer after thelink has been canceled will not be able to view data or otherwise gainaccess to the data storage facility 114. If automatic canceling isprovided by a time-out period, then the expiration time can be set to adefault time period that best maintains confidentiality while beingconvenient for a legitimate user, or may be configured by a user uponauthorized registration. It should be noted that the canceled link is asafeguard in addition to automatic logout of a user, which may occurafter an extended time period of inactivity. FIG. 17 shows a logoutwindow 1702 such as would be displayed after a user has been inactive,after first logging into the network data manager facility. The logoutaction of FIG. 17 helps to make more efficient use of system resources,so that users who are idle can be logged out to make room for otherusers who are attempting to gain access to the network data manager.

FIG. 2 illustrates the operation of the network data manager 108illustrated in FIG. 1. The illustrated operation begins at the flowdiagram box numbered 202, where the network data manager receives a datarequest from a client device. As noted above, the data request includesan access requestor identifier. Next, at the decision box numbered 204,the network data manager determines if the data request comes from aregistered user (such as an owner of a product device who is associatedwith a registration record for the product device) or if the datarequest comes from an authorized partner (such as, in the context of amedical device such as an infusion pump or the like, a physician,physician's authorized representative, personnel at an authorizedmedical clinic, etc., who has replied to an access invitation messageassociated with the product device and who has registered with thenetwork data manager). If either of these conditions is true, thenaccess can be granted. Thus, if the data request is from an authorizeduser, then at box 206 the network data manager can receive upload datafrom the client device, and normal operation then continues. Thereceived upload data may comprise any data capable of being transferredfrom the device, including the product device data described above. Ifthe data request is from an authorized partner, then the network datamanager will grant access in response to the data request and normaloperation then continues. If neither authorized situation applies, thenthe data manager will not grant access in response to the data request.

The data request from an authorized user may be automatically initiatedby the device upon becoming activated or achieving network access. Forexample, when the device gains network data access, it may automaticallysend a message to the network data manager that requests access or loginto the account associated with the device. The message may take the formof an email message or a mobile telephone text message or messageforwarded from a social network facility, or the like. The data requestfrom an authorized partner may comprise a message to the network datamanager that initiates a login process by the authorized partner to login to their own account. Again, the message may take the form of anemail message or a mobile telephone text message or social networkmessage or the like. The authorized partner typically must accept aninvitation from an authorized user to establish an account and share theuser's data. Once an authorized partner has established an account withthe network data manager, the authorized partner can view a list ofpatients from whom they have received data sharing invitations and Maychoose a patient's name from the list, upon which they are grantedaccess to view the data. The data request will typically be receivedthrough the Web site 116 (FIG. 1), which can initiate error processingor otherwise provide the data requestor with options to provideadditional information to become registered and gain access, whereappropriate. Whatever form the data request message takes, be it email,text, or message through social networks, the message will be addressedto the network data manager and, once received, will be acted upon.

FIG. 3 illustrates the operation of the uploader application 110illustrated in FIG. 1. The uploader application is installed in a hostdevice, such as a desktop or laptop computer, mobile computing devicesuch as a mobile phone, tablet computer or the like, or the uploaderapplication 110 may be installed in the product device itself. In eithercase, the first operation illustrated in FIG. 3 is represented by theflow diagram box numbered 302, which shows the uploader operation toauthenticate the product device. The operation to authenticate theproduct device is initiated by launching the uploader application, whichmay be manually launched by a user of the uploader application, or maybe automatically launched. Automatic launch of the uploader applicationmay occur in response to connecting the product device to the hostdevice, in the case of a separate product device and a host device thatexecutes the uploader application, or automatic launch may occur inresponse to a suitable network connection that becomes available to theuploader application. Automatic launch in response to a suitable networkconnection may comprise, for example, a network interface of the hostdevice or product device that detects a broadband connection such thatrelatively high speed data communications with the network data managerwill be supported. For example, upon coming within range of a broadband“WiFi” network, the device may attempt to establish a communicationsession with the network and, upon logging on, the uploader application110 may be launched. The automatic uploader launch may be in place of,or in addition to, the automatic data request message described above.

Once network communication is established by the uploader application,the uploader sends a data request message to the network data manager,providing an access requestor identifier. The access requestoridentifier may comprise, for example, the product device serial numberand/or product number or other indicator of the device's authenticity,registration, and ownership data, an email address and/or passwordcombination, user name and/or password combination, or other loginidentifier information by which registered users may be identified,including combinations thereof. Any combination of one or more of suchinformation may be used as the access requestor identifier to uniquelyidentify a person who is requesting access to the data of the devicethat has been transferred to the network data manager. If the networkdata manager determines that the access requestor identifier isassociated with a data record that identifies a product device having aregistration record, the data requestor is authenticated. That is, thenetwork data manager identifies product user registration data that isassociated with the login information and that is associated with theproduct device. The network data manager then sends an access grantmessage to the client device to confirm that access to the stored datahas been granted.

At the uploader application, data logs are extracted from the productdevice, as indicated by the flow diagram box numbered 304. The productdevice stores a log of operational information and records an index ofupload events to keep track of the last uploaded data log with changeddata. For example, in the case of a product device that is a portablemedicament infusion device such as a portable insulin pump, after anupload occurs, an index number is increased by one incremental valuewhen a change is made to the data log. The uploader application will nottransfer data logs if the index number is not greater than the indexnumber of the last upload event. In this way, duplicate data log recordswill not be extracted and will not be transferred to the network datamanager.

For example, continuing with the case of a portable medicament infusiondevice such as a portable insulin pump, if an insulin dosage isdelivered to the patient, the pump recognizes that the delivery is achange in its operational history, and records that event in the datalog as a change. The time and dosage amount is recorded in the data logand the data log index number is incremented. If another change occurs,such as a dose delivery, or a change to device parameters such as dosagetimes or the like, then the data log index number is again incremented.The device discriminates between events that should initiate a log indexincrement and those events that should not. For example, uploading datafrom the device, and applying electrical power to the device, areexamples of detected events that initiate a log index increment by thedevice. Entering values on the device keypad but not entering orsubmitting the values that would otherwise proceed with processing is anexample of an event that would not initiate a log index increment. Thedevice is adapted to increment the log index in response to events thathave been determined to be worthy of recording at the network datamanager. Upon a requested upload, the current index number will bedifferent from the index number at the time of the last successfulupload, and therefore an upload event will occur. That is, after deviceauthentication, the network data manager sends the last index numberthat the network data manager received in an upload, so that theuploader application only extracts data based on the index number itreceived from the network data manager. As a result, the data logbeginning from after the previously uploaded data log at the old indexnumber, through the data log at the current index number, will betransferred to the network data manager. If the current index number isthe same as the index number of the last upload, then the uploaderapplication recognizes that no data change has occurred since the lastupload, and the uploader application will not perform an upload.

In this way, the network data manager keeps track of the index numberson the device and sends the index number of the last uploaded data tothe device so that the uploader application extracts data from the datalog for sending to the network data manager based on the differencebetween in index number received from the network data manager and thecurrent index number in the data log of the device.

After the changed portion of the data log is identified, the changeddata is extracted for transfer to the network data manager. Thisoperation is represented by box 306 in FIG. 3. The extracted data logand corresponding change items are then transferred to the network datamanager. After a successful upload is received at the network datamanager, the network data manager provides a confirmation that producesa window display at the client device (i.e. host device or productdevice) that permits the user to request access to a data record forviewing of a report, or printing of a report, or both. The windowdisplay typically comprises a data link that is sent from the networkdata manager to the client device, such that the data link can be viewedwith an Internet browser application. Viewing the data link providesaccess to the data record by the client device over the computer networkuntil the data link is automatically canceled, as noted above. That is,the browser is unable to view the data record through the data linkafter the data link has been canceled, such as after a predeterminedtime period has expired. This provides data security so that onlyauthorized users may gain access to the data records associated with aproduct device. If the data link is canceled after a predetermined timeperiod, then the predetermined time period may be set in accordance withprivacy or other security needs. A time period of ten minutes shouldsuffice under most circumstances, to provide a user with time to accessand view or print the reports.

At box 308 of the uploader application processing, the network datamanager receives any requested data record viewing or printing requestfrom the client device via the data link, and processes the request todeliver the requested information, either a window view or a print file.Normal operation then continues.

Operation of the uploader application will be better understood withreference to the state diagrams of FIGS. 4-10 that illustrate operationsof the uploader application.

FIG. 4 shows that operation of the uploader application begins in theDevice Detection state and remains there until a device detected ordevice removed event. The device detected event occurs when a productdevice 102 is connected to the host computer 112 or the product device102, or otherwise gains access to the network 104 (see FIG. 1). Forexample, the uploader application may remain in the Device Detectionstate until the product device integrated with the uploader applicationgains network communication, or until the product device is connected toa host device, which may or may not have an existing networkcommunication. A device removed event occurs when the product device 102is disconnected from the host computer 112 or the product deviceotherwise loses access to the network 104.

Upon occurrence of a device detected event or device removed event, thestate of the uploader application changes to the Standby Processingstate, in which the uploader application remains until the userinitiates an “upload” operation. If the device includes an optional GUI(graphical user interface) display that is produced by the uploaderapplication for product devices containing GUI displays, then the usermay select an upload operation from the GUI display window. For deviceswith a GUI display, the upload operation selection may be accomplishedvia a linked icon or button of the GUI display. The GUI display withselectable upload operation may be produced on a display of the hostdevice or on a display of the product device, or both.

After the user selects the upload operation, the state of the uploaderapplication changes to Authenticate, at which time the uploaderapplication initiates authentication processing. The authenticationprocessing may result in one of three outcomes: (1) the product deviceis not registered with the network data manager, (2) the product deviceis not a recognized device that is maintained in the network datamanager database, or (3) the product device is recognized and isregistered (a “passed” outcome).

The processing to determine the authentication outcome involvesdetermining if the product device is associated with a registrationrecord that identifies a registered user of the product device, in whichcase the authentication passes, and otherwise indicating that aregistration process must be completed for the product device inresponse to determining that the product device is not associated with aregistration record that identifies a registered user of the productdevice, or indicating that the product device is not recognized as avalid device for the uploader application.

If the product device is not recognized, then the state of the uploaderapplication changes from the Authenticate state to the Error state, anduploader application processing subsequently returns to the StandbyProcessing state with an appropriate error message (e.g. “Product notrecognized”) that is generated in the Error state. If the product deviceis recognized but no registration record can be identified, then thestate of the uploader application changes from the Authenticate state tothe New Account/New Device state, in which the uploader applicationprovides an appropriate message such as a request to the user toregister the product device. The user may be required to establish auser account after verifying data relating to user patient status,payment, and the like. The uploader application processing subsequentlyreturns to the Standby Processing state, once registration is complete.The user may then request the upload operation.

If the user is authenticated, then the state of the uploader applicationchanges from Authenticate to Extract Data Logs. If the data logs aresuccessfully extracted as described above in connection with FIG. 3,then the uploader application sends the extracted data logs to thenetwork data manager and the state of the uploader application changesto Upload. If the extraction of data logs fails, such as ifcommunication with the product device is lost, then the state of theuploader application changes from Extract Data Logs to Extraction Error,in which case an appropriate data message error message (e.g.“Extraction Error”) is generated and the state of the uploaderapplication changes to the Standby Processing state to await the nextuser operation.

If authentication is successful, and if extraction of data logs issuccessful, then the state of the uploader application is in the Uploadstate, where the outcome of the state is either a successful upload or afailed upload. If the upload is successful, then the state of theuploader application changes to Done, and the user is presented with adisplay that offers choices between obtaining reports and completingoperations. For example, FIG. 3 shows three choices comprising (1) viewreports, (2) print reports, or (3) selecting Done. Selecting “viewreports” permits the user to view a report online through the display ofthe device or through a Web browser, selecting “print reports” permitsthe user to print a report at a connected printer, and selecting “done”results in the state of the uploader application changing to the StandbyProcessing state, to await the next user operation. The display ofpost-upload selectable operations may be produced on a display of thehost device or on a display of the product device, or both. If theupload operation failed, then the state of the uploader applicationchanges to indicate an upload error, an error message is displayed, andthe state of the uploader application changes to the Standy Processingstate.

As noted above, a successful device authentication and a successful datalog extraction (upload) results in a state of “successful upload” andthe user is presented with a “successful upload” display that offerschoices between obtaining reports and completing operations. Forincreased security, an embodiment of the system guards against a“spoofed” device or other attempt at establishing communication by anunauthorized person with an unauthorized device. For example, the“device” may actually be a computer being used to mimic a device, forthe purpose of surreptitious or nefarious data access. To guard againstsuch possibilities, the operation in FIG. 4 of the “Upload” state withoutput of “Upload successful” may be configured so that the device isconfirmed before the “successful upload” display is provided to thedevice.

Confirming the device may comprise sending a request for confirmationinformation to the device and then validating the received response. Forexample, the network data manager may request the device to provide arandomly selected data record from a randomly selected time in thehistory of the device operation. When the confirmation response isreceived from the device, the network data manager can check theresponse to ensure that it contains correct information. The networkdata manager can check for correctness because the network data managerhas a record of the device history, via prior data uploads from thedevice, and therefore the data records received from the device inresponse to the confirmation request should be identical to thecorresponding data record previously received at the data manager fromthe device for the selected data record and selected time. If they areidentical, then the response to the confirmation request is validated.

For example, the data manager might request that the device provide itsbolus setting at 12:30 pm on Aug. 1, 2012. The data manager will havepreviously received exactly that data via a previous upload from thedevice. If the device seeking to establish communication is a legitimatedevice and is the same device from which the prior upload was received,then the device seeking to establish communication should be able toprovide the requested information. If the device does not provide thecorrect information, the data manager will conclude that the device isan imposter and will not confirm the device, and therefore the user ofthe device will not be presented with a “successful upload” display andwill not be offered a choice between obtaining reports and completingoperations.

Over time, the uploaded data received at the network data manager fromthe device will comprise a relatively large body of data from which thenetwork data manager may choose for confirmation requests. The networkdata manager is free to request confirmation data from the deviceaccording to any and all data available to the network data manager andto a legitimate device. The body of data from which the network datamanager may select can comprise all the operating history data stored atthe device, which will be determined by the storage capacity of thedevice itself. The initial communication with the device may take placeupon manufacturing, with an initial set of upload data from which thenetwork data manager can select for confirming requests. The networkdata manager can then select from the body of data with which the devicehas been initiated. Alternatively, the initial communication may notinclude storing an initial set of data into the device. In thatscenario, the initial confirmation request from the network data managermay involve administrative information known only to a legitimatedevice, such as device serial number, production date and time, power-ondate and time, and the like.

If the device is confirmed, then the selectable post-upload options areprovided in a window display at the client device (i.e. host device orproduct device). As described above in conjunction with FIG. 3, thewindow display typically comprises a data link that is sent from thenetwork data manager to the client device, such that the data link canbe viewed with an Internet browser application. Viewing the data linkprovides access to the data record by the client device over thecomputer network for a predetermined time period, such that access tothe data record is halted upon expiration of the predetermined timeperiod.

FIG. 5 illustrates the operation of the uploader application in theDevice Detection state shown in FIG. 4. In the Device Detection state,the uploader application begins in an Initial state, waiting fornotifications regarding device registration. After a brief wait in theInitial state, involving any system activities for launch of theuploader application, the uploader application changes state to the Waitfor Devices state. A default configuration for the uploader applicationto communicate with product devices is to communicate with such devicesvia a cable connection. Therefore, the uploader application remains inthe Wait for Devices state until it receives a notification of a “deviceconnected” event, at which time the state changes to Check Event, or theuploader application automatically changes to a Poll Attached Cablesstate after a one second time interval of waiting. An alternative to acable (electronic, optical or otherwise) connection is for the productdevice to be connected to the host device via wireless connection, suchas by infrared (IR) transmission, or by radio frequency (RF)transmission. The RF connection may be through, for example, particularprotocols such as “Bluetooth” or “WiFi” or the like. Similarly, theconnection from the product device to the network, or from the hostdevice to the network, or both, may be either wired or wireless.

At the Poll Attached Cables state, the uploader application returns tothe Wait for Devices state if no new connected product devices arefound. That is, the uploader application is capable of communicatingwith multiple product devices that are simultaneously connected to theclient device, and therefore the cable polling is with reference tochecking for any new devices that were not previously detected since thetime of last upload. If the Poll Attached Cables state finds a newdevice, then the state changes to the Check New Device state. If thePoll Attached Cables state determines that a previously connected deviceis now missing, then the state changes to the Check Device state.

At the Check Event state, a notification to initiate the state must haverelated to either a newly connected device, or a removed device. If theevent related to a newly connected device, then the uploader applicationstate is changed to the Check New Device state. If the event related toa removed device, then the uploader application state is changed to theCheck Device state. If the event notification was not recognized, or ifthe product device was not recognized, then the uploader applicationreturns to the Wait for Devices state.

The Check New Device state handles uploader application processing inthe case of a newly connected device. If the newly connected device isrecognized as a valid device for operation with the uploaderapplication, then the state changes to the Standby Processing state (seeFIG. 4). If the newly connected device is not recognized as a validdevice, then the state of the uploader application returns to the Waitfor Devices state. The Check Device state handles uploader applicationprocessing in the case of a missing or removed product device. If themissing or removed device is recognized as a valid device for operationwith the uploader application, then the state changes to the StandbyProcessing state (see FIG. 4). If the missing or removed device is notrecognized as a valid device, then the state of the uploader applicationreturns to the Wait for Devices state.

If the product device is configured to communicate with the clientdevice via a cable, then any drivers, program logic, communicationprotocols, and the like necessary for communication between the productdevice and the uploader application may be included in the cable itself.Such drivers, program logic, communication protocols, and the likenecessary for communication may otherwise be provided with the productdevice itself, such as in the case where the client device (host device)and product device are provided in a single integrated device.

FIG. 6 illustrates the operation of the uploader application in theStandby Processing state shown in FIG. 4. The Standby Processing statehandles processing of the uploader application while it waits for adevice to be connected. An example of the display window for theuploader application, as described above, in the case of waiting for adevice, is illustrated in FIG. 11. FIG. 11 shows a window 1102 with amessage that indicates the user of the uploader application shouldconnect a product device to begin operation. The “Start Upload” buttonin the FIG. 11 display is grayed out to indicate that the uploadoperation is not available, prior to detecting a supported device.

In the Standby Processing state, if a supported device is detected, thedisplay window for the uploader application is changed so that the newdevice is added to a drop-down menu in the display window, as indicatedby the Add Device state in FIG. 6. If a single supported device ispresent, then a display such as illustrated in FIG. 12 is produced. FIG.12 shows a window 1202 in which the “Start Upload” button ishighlighted, to show that it can be selected by the u If the newlyconnected device is a second or subsequent device to be detected, thenthe newly connected device is added to a drop-down menu is produced.FIG. 13 shows a window 1302 in which the device is listed, and otherpreviously-connected devices can be viewed in a drop-down list of thewindow. In either case, the “Start Upload” button is available forselection by the user, to initiate upload processing. If a device isdetected as removed, then the display window for the uploaderapplication is changed so that the removed device is deleted from thedrop-down menu in the display window, as indicated by the Remove Devicestate indicating that the GUI display is updated.

FIG. 7 illustrates the operation of the uploader application in theAuthenticate state shown in FIG. 4. The Authenticate state handlesprocessing of the uploader application after the user of the uploaderapplication has selected “Start Upload” from the GUI display. Inresponse to the “Start Upload” selection, the uploader application statechanges to the Extract Serial & Model Number state. After the requisitedata is extracted, the state of the uploader application is changed toAuthenticate Device, at which time the extracted data is provided to thenetwork data manager, such as via a Web service communication. Thenetwork data manager performs the Web service and validates theextracted product device serial number and model number, as indicated bythe Web Service state. The response from the network data manager, inthe form of a return Web service outcome, will be one of fourconditions: (1) the extracted model number was not recognized, (2) themodel number and serial number were recognized, but there is nocorresponding registration record, (3) the model number and serialnumber were recognized, but correspond to an inactive (i.e., notreleased or sold) product device, or (4) the model number and serialnumber were recognized as being associated with a valid registration,and for that registration a corresponding last uploaded index number isbeing returned.

At the uploader application, the response from the network data manageris checked. For authentication outcomes (1) and (3), extracted devicedata not recognized, an error display message is generated as the outputof the Authenticate state, and the state of the uploader applicationchanges to the Standby Processing state for display of the error message(see FIG. 4). For authentication outcome (2), extracted data recognizedbut no registration located, the state of the uploader application ischanged to the New Account/New Device state (see FIG. 4). Forauthentication outcome (4), device data and registration passed, theuploader application is ready to extract the data logs from the productdevice, and therefore the state of the uploader application is changedto the Extract Logs state (see FIG. 4).

FIG. 8 illustrates the operation of the uploader application in theExtract Logs state shown in FIG. 4. The Extract Logs state handlesprocessing of the uploader application when the most recent data logsare to be extracted from the product device and provided to the networkdata manager. When the uploader application receives a “passed”indication from the network data manager while in the Authenticatestate, it receives a network address for a data link to be used inconnection with the upload operation. For example, the network addressmay comprise a Uniform Resource Locater (URL) for a network location onthe Internet, to which an Internet browser application of the clientdevice may be pointed for communications. That is, the URL comprises adata link that provides access to a data storage facility. As notedabove, the access via the data link is available over the computernetwork for a predetermined time period such that access is halted uponexpiration of the predetermined time period.

In the Extract Logs state, the uploader application changes to theExtract Device Settings state and attempts to determine device settingsfor the product device. Such settings may comprise, as noted previouslyfor the case of a portable insulin pump device, dosage and durationsettings for the pump during daytime, such settings for the pump duringnight time, and the like. If such information cannot be successfullyretrieved from the product device, then an error condition results,initiating an “extraction failed” data message, and the state of theuploader application is changed to an Error state before proceeding tothe Standby Processing state (see FIG. 4). Similarly, the uploaderapplication changes to the Extract Logs state and attempts to retrievedata logs from the product device. As noted above, such data logsinclude operational history of the device and provide a record of dosageand any difficulties in operation since the last upload event. As withthe device settings, if such data log information cannot be successfullyretrieved from the product device, then an error condition results,initiating an “extraction failed” data message, and the state of theuploader application is changed to an Error state before proceeding tothe Standby Processing state (see FIG. 4).

If the extraction of device settings and device data logs are bothsuccessful, then the uploader application changes state to the Convertstate. The Convert state involves processing the extracted data, whichis typically a text string alphanumeric flat data file, to convert theextracted data into a form that is more readily usable by the networkdata manager and more usable by other applications and users. Forexample, in the exemplary embodiment, conversion of the extracted datais from a text format (e.g. ASCII) to a format such as XML (extensiblemarkup language). Those skilled in the art will appreciate that the XMLformat facilitates generating data that is readily usable by a widevariety of applications. After the conversion of the extracted data, thestate of the uploader application is changed to Upload (see FIG. 4).

FIG. 9 illustrates the operation of the uploader application in theUpload state shown in FIG. 4. The Upload state handles processing of theuploader application for transmitting the extracted data logs to thenetwork data manager. The initial operation in the Upload state is forthe uploader application to receive an indication that the extracteddata logs have been successfully retrieved from the product device, atwhich time the state of the uploader application changes to the SendLogs state. In that state, the uploader application sends the extracteddata logs, in their converted XML format, to the Web service at thenetwork data manager. At the network data manager, the extracted datalogs are received, and any errors in the data transfer may be detected,such as through cyclic redundancy code (CRC) processing and the like,and a data link is determined for the uploader application. When thenetwork data manager completes its processing, it sends an uploadresponse back to the uploader application, and the uploader applicationchanges state to the Check Response state, as indicated in FIG. 9.During operation in the Upload state, the uploader application candisplay a progress indication in the upload display window. An exemplaryprogress indication window is shown in FIG. 14, which shows the uploadwindow 1402 with a horizontal window with a bar display for progress,and also provides a “Cancel Upload” button for the case in which theuser wishes to halt the upload operation.

At the Check Response state, the response from the network data managerindicates either (1) a successful upload, or (2) a failed upload. If theupload was (1), successful, then the uploader application receives thedata link and changes state to the Done state (see FIG. 4). If theupload was (2), a failure, then the uploader application receives an“upload failed” indication and the state of the uploader applicationchanges to the Error state to produce a suitable error message and thenchanges to the Standby Processing state for display of the error message(see FIG. 4).

FIG. 9 illustrates the operation of the uploader application in the Donestate shown in FIG. 4. The Done state handles processing in the uploaderapplication for a successful operation from the Check Response state andgenerates an appropriate display. The display shows an “uploadsuccessful” message and waits for further user selection input. That is,the operation in the Done state provides the user with a display havingoptions for (1) viewing a report of a data record, or (2) printing areport of a data record, or for (3) terminating operation of theuploader application. In the display window generated in the Done state,three display buttons for selecting each of the three options areprovided. An exemplary display of the buttons is illustrated in FIG. 15in an Upload Successful window 1502. If the user selects the “ViewReports” button in the window, then the uploader application connects toa data link at a first URL for viewing of a data record reportcorresponding to the authenticated product device for which an uploadwas just completed. If the user selects the “Print Reports” button, thenthe uploader application connects to a data link at a second URL forprinting of a data record report corresponding to the authenticatedproduct device for which an upload was just completed. If the userselects the “Close” button, then the uploader application closes thenetwork data connection and halts operation.

As noted above, a third party may become authorized to share a user'sdata upon being invited by the user to share data and upon replying tothe user's invitation. FIG. 18 is a flow diagram that illustratescomputer operations that implement the feature.

FIG. 18 shows operations of the exemplary embodiment in which a userinitiates the invitation process by selecting an invitation process. Inthe illustrated embodiment, a user accesses the network data managerthrough a Web browser application. FIG. 19 shows a Settings window 1902after a Sharing tab 1904 has been selected by the user to provide theuser with a display button 1906 from which the user may initiate theinvitation process. Third parties with whom the user has alreadyachieved data sharing are shown in the Sharing display of FIG. 19.Although two exemplary users are illustrated, the user may implementdata sharing with none, fewer, or more third parties, and the pop-upwindow listing would be modified accordingly. The window 1902 showsdetails of the respective third party invitation status and sharinginformation.

FIG. 20 shows an invitation pop-up window 2002 that is displayed in theuser's browser after the user has selected “Invite Someone” from thedisplay of FIG. 19. FIG. 20 shows that the user is presented with twooptions, to provide contact information for an invitee via a tab 2004,or to select an invitee from a data listing via a tab 2006. FIG. 20shows details for the user to provide contact information, which is thedefault action in the illustrated embodiment. Thus, FIG. 20 shows a dataentry box 2008 in which the user may enter contact information, such asan email address, for a third party to whom the user wishes to send aninvitation for sharing data from the user's device. A message box 2010is also provided, with text for a default message to the invitee, withthe option for the user to modify the message text as desired. Uponcompletion of data entry, the user may select the Send Invite button2012 to send the invitation or may use the cancel link 2014 to cancelthe invitation operation.

FIG. 21 shows an invitation pop-up window 2102 that is displayed inresponse to the user selecting “Search for Provider” tab 2006 in thedefault invitation pop-up window 2002 (FIG. 20). FIG. 21 shows that alist of third party providers is generated in response to selecting thesearch tab 2006. The list may be populated by, for example, searchinformation inserted into a search box 2104 followed by initiating asearch of available third parties by selecting a search button 2106. Theavailable third party data over which the search is conducted may bepulled from a directory of third parties, or data from a contact list ofthe user or of another person or entity, or may comprise a list ofregistered third parties, or the like. FIG. 21 shows that the user hasselected one third party by selecting a tick box 2108 corresponding tothe third party. Upon completion of selecting the third party to beinvited, the user may select the Send Invite button 2110 to send theinvitation or may use the cancel link 2112 to cancel the invitationoperation. An example of the invitation message sent by the network datamanager and received by the invitee is illustrated in FIG. 24, which isa screenshot of the invitation message 2402. Upon sending the invitationfrom either of the windows 2002 or 2102, the third party who receivesthe invitation to share data may reply to the message and becomeauthorized to share data. As noted above, the third party invitee maycomprise, for example, a physician and/or an authorized member of thephysician's staff, a representative from a partner device producer, aclinician, a certified diabetes educator (CDE), and the like. Uponreplying to the invitation message, the invitee may be requested toprovide contact information and any other data for sharing data. Theinvitee's data may be used to generate a data record with which thethird party will be associated such that the data record includesinformation about the user and the user's device, thereby generating aregistration record that identifies the third party as an authorizedparty for data sharing. The exemplary invitation message of FIG. 24shows that a recipient may be provided with selectable display buttonsthat give the recipient the option to enter their data and establish anew account 2404, or may login to their account if they are alreadyregistered 2406, or may decline to proceed further 2408.

The features described above may be implemented in a wide variety ofelectronic devices. One implementation, as noted above, is an embodimentcomprising a portable infusion pump such as the type suitable fordelivering insulin to a patient. FIGS. 22 and 23 illustrate an infusionpump device 2200 in which the features described above are incorporated.Details of constructions will be described for the infusion pump device.

FIG. 22 is an illustration of an embodiment comprising an infusion pumpdevice 2200 that can perform the functions described herein. FIG. 23illustrates a block diagram of the infusion pump device 2200. Theinfusion pump device 2200 can include an infusion cartridge 2216 havingan infusion set connector 2218, and optionally a glucose meter 2220.Either the infusion cartridge 2216 or the glucose meter 2220 can befunctionally and interchangeably inserted in a receiving slot 2219 ofthe infusion pump device. The infusion pump device 2200 can includememory 2256, transmitter/receiver 2258, processor 2260, output/display2262, and drive mechanism 2264. The housing 2228 of the pump device 2200can be functionally associated with an interchangeable and removableglucose meter 2220 or an infusion cartridge 2216. The infusion cartridge2216 can have an outlet 2252 that can be connected to an infusion setconnector 2218 and an infusion set 2254. The pump device may include aspool 2234 of a delivery mechanism for delivering medicaments such asinsulin.

The housing 2228 of the infusion pump device 2200 can each be of anysuitable shape and size. For instance, the housing 2228 may be extendedand tubular, or in the shape of a square, rectangle, circle, cylinder orthe like. The housing 2228 may be dimensioned so as to be comfortablyassociated with a user and/or hidden from view, for instance, within theclothes of a u For some embodiments, the housing 2228 of the pump device2200 may have a width of about 2.5 inches to about 3.5 inches, a heightof about 1 inch to about 2 inches and a thickness of about 0.2 inches toabout 0.6 inches. The materials of the housing 2228 may vary as well. Insome embodiments, housing 2228 of the pump device 2200 may be a verywater-tight, plastic housing that is glued together permanently.

The infusion pump device 2200 may include an output/display 2262. Thetype of output/display 2262 may vary as may be useful for particularapplication. The type of visual output/display may include LCD displays,LED displays, plasma displays, OLEO displays and the like. Theoutput/display 2262 may also be an interactive or touch sensitive screenhaving an input device such as a touch screen, a capacitance screen, aresistive screen or the like. In some embodiments, the output/display2244 of the pump device 2200 may be an OLEO screen or an LCD screen or acapacitance touch screen. The pump device 2200 may additionally includea keyboard or other input device known in the art for data entry, whichmay be separate from the display. The output/display 2262 may alsoinclude a capability to operatively couple to a secondary display devicesuch as a laptop computer, mobile communication device such as asmartphone or personal digital assistant (PDA), or the like.

The pump device may have wired or wireless communication capability suchas for the sending and receiving of data as is known in the art. Thewireless capability may be used for a variety purposes, includingupdating of any software or firmware for the processor of the device.The wireless communication capability may vary including, e.g., atransmitter and/or receiver, radiofrequency (RF) transceiver, WIFIconnection, infrared or Bluetooth® communication device. The wiredcommunication capability may also vary including, e.g., USB or SO port,flash drive port, or the like. In some embodiments, the pump device 2200has a network communications block such as a transmitter/receiver 2258having a radiofrequency (RF) transceiver, that allows the pump device tocommunicate with other electronic devices and to be used interchangeablywithout loss of data or information during an infusion protocol with asingle infusion cartridge 2216. Data may be transferred between theprocessor of the pump device and a second electronic device by radiosignal, optical transmission, or any other suitable means. The pumpdevice 2200 may be used as stand-alone device as well.

The infusion pump device 2200 may also include GPS functionality, phonefunctionality, warning and/or alarm programming; music storage andreplay functionality, e.g., an MP3 player; a camera or video mechanism;auto scaling capabilities, and/or one or more video type games or otherapplications developed by third parties for use thereon. The pump device2200 may also include an accelerometer, for instance, which may be usedfor changing presented estimates, wherein instead of scrolling through amenu of options or using a numerical keypad, values can be input orchanged via the accelerometer, such as by gesturing with or otherwiseshaking the device.

As shown in FIG. 23, the pump device 2200 has a processor 2260 thatfunctions to control the overall functions of the device. The processor2260 may include programming that functions to control the respectivedevice and its components. The processor 2260 may communicate withand/or otherwise control the drive mechanism, output/display, memory,transmitter/receiver and the like. The processor of the pump device maycommunicate with the processor of other electronic devices, for example,through the transmitter/receiver. The processor may include programmingthat can be executed to control the infusion of insulin or othermedicament from the cartridge, the data to be displayed by the display,the data to be transmitted via the transmitter, etc. The processor mayalso include programming that allows the processor to receive signalsand/or other data from an input device, such as a sensor that sensespressure, temperature, and the like, that may be included as a part ofthe device or used in conjunction therewith. The processor 2260 mayreceive signals, for instance, from a transmitter/receiver on a bloodglucose monitor and store the signals in the memory.

The processor 2260 may also include additional programming to allow theprocessor to learn user preferences and/or user characteristics and/oruser history data, for instance, to implement changes in use suggestionsbased on detected trends, such as weight gain or loss; and may includeprogramming that allows the device to generate reports, such as reportsbased upon user history, compliance, trending, and/or other such data.Additionally, pump device embodiments of the disclosure may include a“power off” or “suspend” function for suspending one or more functionsof the device, such as suspending a delivery protocol, and/or forpowering off the device or the delivery mechanism thereof. For someembodiments, two or more processors may be used for controller functionof the pumps, including a high power controller and a low powercontroller used to maintain programming and pump functions in low powermode in order to save battery life.

The pump device 2200 may include a memory device 2256. The memory device2256 may be any type of memory capable of storing data and communicatingthat data to one or more other components of the device, such as theprocessor. The memory may be one or more of a Flash memory, SRAM, ROM,DRAM, RAM, EPROM, dynamic storage, and the like. For instance, thememory may be coupled to the processor and configured to receive andstore input data and/or store one or more template or generated deliverypatterns. For example, the memory can be configured to store one or morepersonalized (e.g., user defined) delivery profiles, such as a profilebased on a user's selection and/or grouping of various input factors (asdescribed below); past generated delivery profiles; recommended deliveryprofiles; one or more traditional delivery profiles, e.g., square wave,dual square wave, basal and bolus rate profiles; and/or the like. Thememory can also store user information, history of use, glucosemeasurements, compliance, an accessible calendar of events, and thelike. In some embodiments, the memory 2230 of the pump device may beabout 200 kB up to about 3 GB.

The pump device 2200 may include a power charging mechanism in somecases, such as a USB port, induction charger, or the like. The powercharging system may be used to charge a power storage cell such as arechargable battery of the pump device. Some embodiments may use arechargable battery such as a NiCad battery, LiPo battery, NiMH batteryor the like. In some embodiments, the power charging mechanism 2268 maybe a USB port. As such, all data may be kept in the pump device forquick and easy downloading of data to a computer, other pump device,network, etc. using the USB port. The USB port may also provide the pumpdevice 2200 with power charging. In some instances, the power chargingmechanism 2268 may be an induction charging device 2270.

The uploader application described herein, as well as the network datamanager and other components whose operation is described herein, may beprovided as a computer program product embodied in a non-transitorycomputer readable storage medium containing computer implementableinstructions that may be executed by a computer device. The storagemedium may comprise, for example, flash memory, an optical disc such asdata CD or DVD, or other computer-readable data storage device. Thecomputer implementable instructions stored on the storage mediumcomprise instructions that when executed by a computer processor willprovide the operation and functions described herein. The computerdevice for executing the enhanced media work may comprise a wide varietyof computer devices that operate under control of a processor andinclude memory and input/output facilities, such as, for example, amobile device or a tablet computer or a desktop or laptop computer. Themobile device may comprise, for example, a portable insulin pump deviceor other readily transported device that operates under control of aprocessor and includes memory and interfaces for input and output ofdata.

Some embodiments may be directed to a kit, which kit may include adevice and/or a system for the transfer of device data over a computernetwork as described herein. Specifically, the kit may include one ormore of a portable electronic device, such as an infusion device havinga drive mechanism and receiving an infusion cartridge, as well asinstructions for using the same, and may include an aliquot of themedicament, e.g., insulin to be delivered, as well as infusion settubing. The instructions may be in written, audio, or pictorial form andmay be included in a written manual and/or on an instruction CD or DVD,MP3 file, or accessible via a network. In certain embodiments, atraining video may be included, for instance, on a separate DVD or othermedium, may be accessible via a network, or may be included asprogramming on the portable infusion device. For instance, in certainembodiments, the portable infusion device may include a training module.The training module may be included as programming accessible by theprocessor of the device, wherein the software is configured to instructa user in the proper use of the device.

It should be noted that the methods, systems, and devices discussedabove are intended merely to be examples. Various embodiments may omit,substitute, or add various procedures or components as appropriate. Forexample, it should be appreciated that, in alternative embodiments, themethods may be performed in an order different from that described, andvarious steps may be added, omitted, or combined. Also, featuresdescribed with respect to certain embodiments may be combined in variousother embodiments. Different aspects and elements of the embodiments maybe combined in a similar manner. Also, it should be emphasized thattechnology evolves and, thus, many of the elements are examples andshould not be interpreted to limit the scope of the invention.

Specific details are given in this description to provide a thoroughunderstanding of the embodiments. Nevertheless, it will be understood byone of ordinary skill in the art that the embodiments may be practicedwithout these specific details. For example, well-known circuits,processes, algorithms, structures, and techniques have been shownwithout unnecessary detail in order to avoid obscuring the embodiments.Further, the headings provided herein are intended merely to aid in theclarity of the descriptions of various embodiments, and should not beconstrued as limiting the scope of the invention or the functionality ofany part of the invention. For example, certain methods or componentsmay be implemented as part of other methods or components, even thoughthey are described under different headings.

It is noted that embodiments may have been described as a process thatis depicted as a flow diagram or block diagram. Although each diagrammay describe the process as a sequential series of operations, many ofthe operations can be performed in parallel or concurrently. Inaddition, the order of the operations may be rearranged. A process mayhave additional steps not included in the figures.

The description above has been provided in terms of presently preferredembodiments so that an understanding of the present invention can beconveyed. There are, however, many configurations and techniques fordata management systems that were not specifically described herein, butwith which the present invention is applicable. The present inventionshould therefore not be seen as limited to the particular embodimentsdescribed herein, but rather, it should be understood that the presentinvention has wide applicability with respect to data managementgenerally. All modifications, variations, or equivalent arrangements andimplementations that are within the scope of the attached claims shouldtherefore be considered within the scope of the invention.

We claim:
 1. A portable infusion system for transferring data over acomputer network, the portable infusion system comprising: a memory thatstores data of a portable infusion device; a network communicationsblock adapted for communications with the computer network; a processorcoupled to the memory and the network communications block; wherein theprocessor responds to an upload request by authenticating the portableinfusion device and extracting a data log comprising at least a portionof the data stored in the memory and an identifier associated with theportable infusion device, and wherein the processor sends the extracteddata log and identifier over the computer network to a network datamanager, and receives an upload success message from the network datamanager in response to a successful sending of the extracted data logand a determination that the identifier is associated with a data recordat the network data manager that identifies a product device having aregistration record; wherein the upload success message includes a datalink, such that the data link provides access to the data record by theportable infusion system until the data link is automatically canceled,wherein access to the data record is halted upon the data link beingcanceled.
 2. The system of claim 1, wherein the data link isautomatically canceled upon expiration of a predetermined time period.3. The system of claim 1, wherein the portable infusion system includesa portable infusion device that includes the memory, and furthercomprising a drive mechanism for infusion of a fluid from the portableinfusion device.
 4. The system of claim 1, further including a hostcomputer that comprises a host processor, the memory, and the networkcommunications block, wherein the host computer receives the extracteddata log and identifier from device memory of the portable infusiondevice, and the host processor sends the extracted data log andidentifier over the computer network to a network data manager.
 5. Amethod of transferring data over a computer network from a portableinfusion system, the method comprising: responding to an upload requestby extracting a data log comprising at least a portion of data stored inmemory of a portable infusion device and an identifier associated withthe portable infusion device; sending the extracted data log andidentifier over the computer network to a network data manager, andreceiving an upload success message from the network data manager inresponse to a successful sending of the extracted data log and adetermination that the identifier is associated with a data record atthe network data manager that identifies a product device having aregistration record; wherein the upload success message includes a datalink, such that the data link provides access to the data record by theportable infusion system until the data link is automatically canceled,wherein access to the data record is halted upon the data link beingcanceled.
 6. The method of claim 5, wherein the data link isautomatically canceled upon expiration of a predetermined time period.7. The method of claim 5, wherein responding comprises authenticating aportable infusion device having a drive mechanism for infusion of afluid from the portable infusion device at a host computer thatcommunicates with the portable infusion device.
 8. The method of claim7, wherein responding comprises receiving the extracted data log andidentifier at the host computer from device memory of the portableinfusion device; and wherein the host computer sends the extracted datalog and identifier over the computer network to a network data manager.9. A method of accessing stored data over a computer network through anetwork data manager, the method comprising: receiving a request messageat the network data manager from a client device for access to a datastorage facility, the request message including an access requestoridentifier; determining at the network data manager that the accessrequestor identifier is associated with a data record that identifies aproduct device having a registration record; and transmitting a datalink to the client device, wherein the data link provides access to thedata record by the client device over the computer network for apredetermined time period such that access to the data record is haltedupon expiration of the predetermined time period.
 10. The method ofclaim 9, further including: sending an access grant message from thenetwork data manager to the client device for access to the stored data;receiving a data request from the client device in response to theaccess grant message, requesting access to a data record of the storeddata at the data storage facility; providing the requested data recordto the client device over the computer network only if the predeterminedtime period has not expired.
 11. The method of claim 10, wherein thedata request comprises a request to view the data record.
 12. The methodof claim 9, wherein the product identifier relates to a portable insulinpump device.
 13. The method of claim 9, wherein the product identifierrelates to a product device, and the product device and client deviceare integrated together into a single device.
 14. The method of claim 9,wherein the data link comprises an Internet link that is accessed via anInternet browser application executing on the client device.
 15. Themethod of claim 9, wherein the associated data record further identifiesan authorized access partner who has replied to an access invitationmessage associated with the product device.
 16. The method of claim 16,wherein determining comprises: receiving login information from theclient device at the network data manager; and identifying accesspartner registration data that is associated with the login informationand that is associated with the product device.
 17. The method of claim17, wherein the access partner registration data and login informationare stored at the data storage facility.
 18. The method of claim 9,wherein the associated data record further identifies a product user whois associated with the registration record of the product device.